计算机网络(第7版) |
您所在的位置:网站首页 › udp最大发送速率 应用软件是什么 › 计算机网络(第7版) |
1. 试说明运输层在协议栈中的地位和作用,运输层的通信和网络层的通信有什么重要区别?为什么运输层是必不可少的? 运输层处于面向通信部分的最高层,同时也是用户功能中的最低层,向它上面的应用层提供服务。运输层为应用进程之间提供端到端的逻辑通信,但网络层是为主机之间提供逻辑通信(面向主机,承担路由功能,即主机寻址及有效的分组交换)。 各种应用进程之间通信需要“可靠或尽力而为”的两类服务质量,必须由运输层以复用和分用的形式加载到网络层。 2.网络层提供数据报或虚电路服务对上面的运输层有何影响? 网络层提供数据报或虚电路服务不影响上面的运输层的运行机制。 但提供不同的服务质量。 3.当应用程序使用面向连接的 TCP 和无连接的 IP 时,这种传输是面向连接的还是面向无连接的? 都是。这要在不同层次来看,在运输层是面向连接的,在网络层则是无连接的。 4.试用画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上,而这条运输连接有复用到IP数据报上。 6.接收方收到有差错的 UDP 用户数据报时应如何处理 简单地丢弃 7.如果应用程序愿意使用 UDP 来完成可靠的传输,这可能吗?请说明理由。 可能,但应用程序中必须额外提供与 TCP 相同的功能 8.为什么说 UDP 是面向报文的,而 TCP 是面向字节流的? ① 发送方 UDP 对应用程序交下来的报文,在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。接收方 UDP 对 IP 层交上来的 UDP 用户数据报,在去除首部后就原封不动地交付上层的应用进程,一次交付一个完整的报文。发送方 TCP 对应用程序交下来的报文数据块,视为无结构的字节流(无边界约束,课分拆/合并),但维持各字节。 ② UDP 是面向报文的:发送方的 UDP 对应用程序交下来的报文,在添加了首部之后就向下交付,UDP 对应用层交付下来的报文即不合并也不拆分,而是保留这些报文的边界,应用层交给 UDP 多长的报文,UDP 就照样发送,即一次发送一个报文,接收方 UDP 对下方交上来的 UDP 用户数据报,在去除首部之后就原封不动的交付给上层的应用程序,一次交付一个完整报文,所以是 UDP 是面向报文的 ③ TCP 是面向字节的:发送方 TCP 对应用程序交下来的报文数据块,视为无结构的字节流(无边界约束,可拆分/合并),但维持各字节流顺序(相对顺序没有变),TCP发送方有一个发送缓冲区,当应用程序传输的数据块太长,TCP 就可以把它划分端一些再传输,如果应用程序一次只传输一个字节,那么 TCP 可以等待积累足够多的字节后再构成报文端发送出去,所以 TCP 的面向字节的 9.端口的作用是什么?为什么端口要划分为三种? 端口的作用是对 TCP/IP 体系的应用进程进行统一的标志,使运行不同操作系统的计算机的应用进程能够互相通信。 熟知端口号:数值一般为 0~1023,标记常规的服务进程如 FTP 是 21,DNS 是 53,HTTP 是 80 等 登记端口号:数值为 1024~49151,标记没有熟知端口号的非常规的服务进程 短暂端口号:数值为 49152~65535,客户进程运行时动态选择 把端口划分为 3 类是因为:避免端口号重复,无法区分应用进程。二是因特网上的计算机通信都是采用 C/S 方式,在客户发起通信请求时,必须知道服务器的端口,对应一些重要的应用程序,必须让所有用户知道。 10.试说明运输层中伪首部的作用。 用于计算运输层数据报校验和。 伪首部(pseudo header),通常有 TCP 伪首部和 UDP 伪首部。在 UDP 伪首部中,包含 32 位源 IP 地址,32 位目的 IP 地址,8 位协议,16 位 UDP 长度。通过伪首部的校验,UDP 可以确定该数据报是不是发给本机的,通过首部协议字段,UDP 可以确认有没有误传。 11.某个应用进程使用运输层的用户数据报 UDP,然而继续向下交给 IP 层后,又封装成 IP 数据报。既然都是数据报,可否跳过 UDP 而直接交给IP层?哪些功能 UDP 提供了但 IP 没提提供? IP数据报只能找到目的主机而无法找到目的进程。UDP 提供对应用层的复用和分用功能,并提供对数据部分的差错检验。 12.一个应用程序用 UDP,到 IP 层把数据报在划分为 4 个数据报片发送出去,结果前两个数据报片丢失,后两个到达目的站。过了一段时间应用程序重传 UDP,而 IP 层仍然划分为 4 个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问:在目的站能否将这两次传输的 4 个数据报片组装成完整的数据报?假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。 不行。重传时,IP 数据报的标识字段会有另一个标识符。 仅当标识符相同的 IP 数据报片才能组装成一个 IP 数据报。前两个 IP 数据报片的标识符与后两个 IP 数据报片的标识符不同,因此不能组装成一个IP数据报。 13.一个 UDP 用户数据的数据字段为 8192 字节。在数据链路层要使用以太网来传送。试问应当划分为几个 IP 数据报片?说明每一个 IP 数据报字段长度和片偏移字段的值。 UDP 用户数据报的长度 = 8192 + 8 = 8200 B 以太网数据字段最大长度为 1500 B。若 IP 首部为 20 字节,则 IP 数据报的数据部分最多只能有 1480 B。8200=1480∗5+8008200=1480∗5+800,因此划分的数据报片共 6 个。 数据字段的长度:前 5 个是 1480字节,最后一个是 800 字节。 第 1 个数据报片的片偏移字节为 0 B; 第 2 个数据报片的片偏移字节为 1480 B。 第 3 个数据报片的片偏移字节为 2960 B。 第 4 个数据报片的片偏移字节为 4440 B。 第 5 个数据报片的片偏移字节为 5920 B。 第 6 个数据报片的片偏移字节为 7400 B。 14.一 UDP 用户数据报的首部十六进制表示是:06 32 00 45 00 1C E2 17。试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器发送给客户?使用 UDP 的这个服务器程序是什么? 把首部的 8 个字节的数值写成二进制表示的数值,如下所示: 16.在停止等待协议中如果不使用编号是否可行?为什么? 分组和确认分组都必须进行编号,才能明确哪个分则得到了确认。 停止等待协议要点: ① 停止等待协议用于通信系统中,两个相连的设备相互发送信息时使用,以确保信息不因丢包或包乱序而丢失,是最简单的自动重传请求方法。 只有收到序号正确的确认帧 ACKn 后,才更新发送状态变量 V(S)一次,并发送新的数据帧。 ② 接收端接收到数据帧时,就要将发送序号 N(S) 与本地的接收状态变量 V®相比较。 若二者相等就表明是新的数据帧,就收下,并发送确认。否则为重复帧,就必须丢弃。但这时仍须向发送端发送确认帧 ACKn,而接收状态变量V®和确认序号 n 都不变。 连续出现相同发送序号的数据帧,表明发送端进行了超时重传。连续出现相同序号的确认帧,表明接收端收到了重复帧。 ③ 发送端在发送完数据帧时,必须在其发送缓存中暂时保留这个数据帧的副本。这样才能在出差错时进行重传。只有确认对方已经收到这个数据帧时,才可以清除这个副本。 实用的CRC 检验器都是用硬件完成的。 ④ CRC 检验器能够自动丢弃检测到的出错帧。因此所谓的“丢弃出错帧”,对上层软件或用户来说都是感觉不到的。 发送端对出错的数据帧进行重传是自动进行的,因而这种差错控制体制常简称为ARQ(Automatic Repeat reQuest),直译是自动重传请求,但意思是自动请求重传。 17.在停止等待协议中,如果收到重复的报文段时不予理睬(即悄悄地丢弃它而其他什么也没做)是否可行?试举出具体的例子说明理由。 21.使用连续 ARQ 协议中,发送窗口大小事 3,而序列范围 [0, 15],而传输媒体保证在接收方能够按序收到分组。在某时刻,接收方,下一个期望收到序号是 5。试问: (1)在发送方的发送窗口中可能有出现的序号组合有哪几种? (2)接收方已经发送出去的、但在网络中(即还未到达发送方)的确认分组可能有哪些?说明这些确认分组是用来确认哪些序号的分组。 (1)在接收方,下一个期望收到的序号是 5。这表明序号到 4 为止的分组都已收到。若这些确认都已到达发送方,则发送窗口最靠前,其范围是 [5, 7]。 假定所有的分组都丢失了,发送方都没有收到这些确认。这时,发送窗口最靠后,应为 [2, 4]。因此,发送窗口可以是 [2, 4],[3, 5],[4, 6],[5, 7] 中的任何一个。 (2)接收方期望收到的序号 5 的分组,说明序号为 2,3,4 的分组都已收到,并且发送了确认。对序号为 1 的分组的确认肯定被发送方收到了,否则发送方不可能发送 4 号分组。可见,对序号为 2,3,4 的分组的确认有可能仍滞留在网络中。这些确认是用来确认序号为 2,3,4 的分组的。 22.主机 A 向主机 B 连续发送了两个 TCP 报文段,其序号分别为 70 和 100。试问: (1)第一个报文段携带了多少个字节的数据? (2)主机 B 收到第一个报文段后发回的确认中的确认号应当是多少? (3)如果主机 B 收到第二个报文段后发回的确认中的确认号是 180,试问 A 发送的第二个报文段中的数据有多少字节? (4)如果 A 发送的第一个报文段丢失了,但第二个报文段到达了 B。B 在第二个报文段到达后向 A 发送确认。试问这个确认号应为多少? (1)第一个报文段的数据序号是 70 到 99,共 30 字节的数据。 (2)B 期望收到下一个报文段的第一个数据字节的序号为 100,因此确认号为 100。 (3)A 发送的第二个报文段中的数据中的字节数是 180 - 100 = 80 字节【实际上,就是序号 100 到序号 179 的字节,即 179 - 100 + 1 = 80 字节】 (4)B 在第二个报文段到达后向 A 发送确认,其确认号应为 70。【报文段丢失,就会重复发送确认上一个未收到的报文段第一个序号,即 70】 24.一个 TCP 连接下面使用 256 kb/s 的链路,其端到端时延为 128 ms。经测试,发现吞吐量只有 120 kb/s。试问发送窗口 W 是多少?(提示:可以有两种答案,取决于接收端发出确认的时机)。 设发送窗口 = W(bit),再设发送端连续发送完窗口内的数据所需要的时间 = T。有两种情况: (a) 接收端在收完一批数据的最后才发出确认,因此发送端经过 (256 ms + T) 后才能发送下一个窗口的数据。 (b) 接收端每收到一个很小的报文段就发回确认,因此发送端经过比 256 ms 略多一些的时间即可在发送数据。因此每经过 256 ms 就能发送一个窗口的数据。 25.为什么在 TCP 首部中要把 TCP 端口号放入最开始的 4 个字节? 在 ICMP 的差错报文中要包含 IP 首部后面的8个字节的内容,而这里面有 TCP 首部中的源端口和目的端口。当 TCP 收到 ICMP 差错报文时需要用这两个端口来确定是哪条连接出了差错。 26.为什么在 TCP 首部中有一个首部长度字段,而 UDP 的首部中就没有这个这个字段? TCP 首部除固定长度部分外,还有选项,因此 TCP 首部长度是可变的。UDP 首部长度是固定的。 27.一个 TCP 报文段的数据部分最多为多少个字节?为什么?如果用户要传送的数据的字节长度超过 TCP 报文字段中的序号字段可能编出的最大序号,问还能否用 TCP 来传送? 29.在使用 TCP 传送数据时,如果有一个确认报文段丢失了,也不一定会引起与该确认报文段对应的数据的重传。试说明理由。 还未重传就收到了对更高序号的确认。 因为 TCP 接收方只会对按序到达的最后一个分组发送确认 当对更高的序号确认了 意味着已经到达了,即不用重传了。 30.设 TCP 使用的最大窗口为 65535 字节,而传输信道不产生差错,带宽也不受限制。若报文段的平均往返时延为 20 ms,问所能得到的最大吞吐量是多少?
① 慢开始: 在主机刚刚开始发送报文段时可先将拥塞窗口 cwnd 设置为一个最大报文段 MSS 的数值。在每收到一个对新的报文段的确认后,将拥塞窗口增加至多一个 MSS 的数值。用这样的方法逐步增大发送端的拥塞窗口 cwnd,可以分组注入到网络的速率更加合理。 ② 拥塞避免: 当拥塞窗口值大于慢开始门限时,停止使用慢开始算法而改用拥塞避免算法。拥塞避免算法使发送的拥塞窗口每经过一个往返时延 RTT 就增加一个 MSS 的大小。 ③ 快重传算法规定: 发送端只要一连收到三个重复的 ACK 即可断定有分组丢失了,就应该立即重传丢手的报文段而不必继续等待为该报文段设置的重传计时器的超时。 ④ 快恢复算法: 当发送端收到连续三个重复的 ACK 时,就重新设置慢开始门限 ssthresh 与慢开始不同之处是拥塞窗口 cwnd 不是设置为 1,而是设置为 ssthresh 若收到的重复的 ACK 为 n 个(n>3),则将 cwnd 设置为 ssthresh 若发送窗口值还容许发送报文段,就按拥塞避免算法继续发送报文段。若收到了确认新的报文段的 ACK,就将 cwnd 缩小到 ssthresh。 ⑤ 乘法减小: 是指不论在慢开始阶段还是拥塞避免阶段,只要出现一次超时(即出现一次网络拥塞),就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5。当网络频繁出现拥塞时,ssthresh 值就下降得很快,以大大减少注入到网络中的分组数。 ⑥ 加法增大: 是指执行拥塞避免算法后,在收到对所有报文段的确认后(即经过一个往返时间),就把拥塞窗口 cwnd 增加一个 MSS 大小,使拥塞窗口缓慢增大,以防止网络过早出现拥塞。 38.设 TCP 的 ssthresh 的初始值为 8 (单位为报文段)。当拥塞窗口上升到 12 时网络发生了超时,TCP 使用慢开始和拥塞避免。试分别求出第 1 次到第 15 次传输的各拥塞窗口大小。你能说明拥塞控制窗口每一次变化的原因吗? 拥塞窗口大小及变化原因见下表: 39.TCP 的拥塞窗口 cwnd 大小与传输轮次 n 的关系如表 5.1 所示: (1)试画出如教材中图 5-25 所示的拥塞窗口与传输轮次的关系曲线。 (2)指明 TCP 工作在慢开始阶段的时间间隔。 (3)指明 TCP 工作在拥塞避免阶段的时间间隔。 (4)在第 16 轮次和第 22 轮次之后发送方是通过收到三个重复的确认还是通过超时检测到丢失了报文段? (5)在第 1 轮次,第 18 轮次和第 24 轮次发送时,门限 ssthresh 分别被设置为多大? (6)在第几轮次发送出第 70 个报文段? (7)假定在第 26 轮次之后收到了三个重复的确认,因而检测出了报文段的丢失,那么拥塞窗口 cwnd 和门限 ssthresh 应设置为多大? 40.TCP 在进行流量控制时是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起的分组丢失的情况?如有,请举出三种情况 不是因为拥塞而引起分组丢失的情况是有的,举例如下: ① 当 IP 数据报在传输过程中需要分片,但其中一个数据报片未能及时到达终点,而终点组装 IP 数据报已超时,因而只能丢弃该数据报。 ② IP 数据报已经到达终点,但终点的缓存没有足够的空间存放此数据报。 ③ 数据报在转发过程中经过一个局域网的网桥,但网桥在转发该数据报的帧时没有足够的储存空间而只好丢弃。 41.用 TCP 传送 512 字节的数据。设窗口为 100 字节,而 TCP 报文段每次也是传送 100 字节的数据。再设发送端和接收端的起始序号分别选为 100 和 200,试画出类似于教材中图 5-31 的工作示意图。从连接建立阶段到连接释放都要画上。 要传送的 512 B 的数据必须划分为 6 个报文段传送,前 5 个报文段各 100 B,最后一个报文段传送 12 B。下图是双方交互的示意图。下面进行简单的解释。 【----- 进行三报文握手 -----】 报文段 #1:A 发起主动打开,发送 SYN 报文段,除以 SYN-SENT 状态,并选择初始序号 seq = 100。B 处于 LISTEN 状态。 报文段 #2:B 确认 A 的 SYN 报文段,因此 ack = 101(是 A 的初始序号加 1)。B选择初始序号 seq = 200。B 进入到 SYN-RCVD 状态。 报文段 #3:A 发送 ACk 报文段来确认报文段 #2,ack = 201(是 B 的初始序号加 1)。A 没有在这个报文段中放入数据。因为 SYN 报文段 #1 消耗了一个序号,因此报文段 #3 的序号是 seq = 101。这样,A 和 B 都进入了 ESTABLISHED 状态。 【----- 三报文握手完成 -----】 42.在图 5-29 中所示的连接释放过程中,主机 B 能否先不发送 ACK = x + 1 的确认?(因为后面要发送的连接释放报文段中仍有 ACK = x + 1 这一信息) 43.在图 5-30 中,在什么情况下会发生从状态 SYN-SENT 到状态 SYN-RCVD 的变迁? 44.试以具体例子说明为什么一个运输连接可以有多种方式释放。可以设两个互相通信的用户分别连接在网络的两结点上。 设 A,B建立了运输连接。 协议应考虑一下实际可能性: A 或 B 故障,应设计超时机制,使对方退出,不至于死锁; A主动退出,B被动退出 B主动退出,A被动退出 45.解释为什么突然释放运输连接就可能会丢失用户数据,而使用 TCP 的连接释放方法就可保证不丢失数据。 当主机 1 和主机 2 之间连接建立后,主机 1 发送了一个 TCP 数据段并正确抵达主机 2,接着主机 1 发送另一个TCP数据段,这次很不幸,主机 2 在收到第二个 TCP 数据段之前发出了释放连接请求,如果就这样突然释放连接,显然主机 1 发送的第二个 TCP 报文段会丢失。 而使用 TCP 的连接释放方法,主机 2 发出了释放连接的请求,那么即使收到主机 1 的确认后,只会释放主机 2 到主机 1 方向的连接,即主机 2 不再向主机 1 发送数据,而仍然可接收主机 1 发来的数据,所以可保证不丢失数据。 46.试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能会出现什么情况。 3 次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。 假定 B 给 A 发送一个连接请求分组,A 收到了这个分组,并发送了确认应答分组。按照两次握手的协定,A 认为连接已经成功地建立了,可以开始发送数据分组。可是,B 在 A 的应答分组在传输中被丢失的情况下,将不知道 A 是否已准备好,不知道 A 建议什么样的序列号,B 甚至怀疑 A 是否收到自己的连接请求分组,在这种情况下,B 认为连接还未建立成功,将忽略 A 发来的任何数据分组,只等待连接确认应答分组。而 A 发出的分组超时后,重复发送同样的分组。这样就形成了死锁。 47.一个客户向服务器请求建立 TCP 连接。客户在 TCP 连接建立的三次握手中的最后一个报文段中捎带上一些数据,请求服务器发送一个长度为 L 字节的文件。假定: (1)客户和服务器之间的数据传输速率是 R 字节/秒,客户与服务器之间的往返时间是 RTT(固定值)。 (2)服务器发送的 TCP 报文段的长度都是 M 字节,而发送窗口大小是 nM 字节。 (3)所有传送的报文段都不会出错(无重传),客户收到服务器发来的报文段后就及时发送确认。 (4)所有的协议首部开销都可忽略,所有确认报文段和连接建立阶段的报文段的长度都可忽略(即忽略这些报文段的发送时间)。 试证明,从客户开始发起连接建立到接收服务器发送的整个文件多需的时间 T 是:T = 2RTT + L/R,当 nM > R(RTT) + M 或 T= 2RTT + L/R + (K - 1)[ M/R + RTT - nM/R],当 nM < R(RTT) + M 其中,K=『L/nM』,符号『x』表示若 x 不是整数,则把 x 的整数部分加 1。 (提示:求证的第一个等式发生在发送窗口较大的情况,可以连续把文件发送完。求证的第二个等式发生在发送窗口较小的情况,发送几个报文段后就必须停顿下来,等收到确认后再继续发送。建议先画出双方交互的时间图,然后再进行推导。) 48.网络允许的最大报文段长度为 128 字节,序号用 8 比特表示,报文段在网络中的寿命为 30 s。求发送报文段的一方所能达到的最高数据率。 根据题意,先可以做出以下一些假设: (1)本题不是使用 TCP 协议,因为序号字段是 8 位,而不是 TCP 的 32 位。 (2)既然不是使用 TCP 协议,当然也不是使用 TCP 协议得到首部。现在的报文段的首部是什么样子,和我们解题没有关系。我们不用管它。我们只需要知道的是,现在的报文段的首部有一个序号字段。 (3)显然,现在不是给报文中的每一个字节编上序号,而是给每一个报文编上序号。 (4)报文段的传送应当使用滑动窗口协议(而不是停止等待协议),这样可得到较高的效率。 49.下面是以十六进制格式存储的一个 UDP 首部: CB84000D001C001C 试问: (1) 源端口号是什么? (2) 目的端口号是什么? (3) 这个用户数据报的总长度是什么? (4) 数据长度是多少? (5)这个分组是从客户到服务器还是从服务器到客户? (6) 客户进程是什么 51.在以下几种情况下,UDP 的检验和在发送时数值分别是多少? (1)发送方决定不使用检验和。 (2)发送方使用检验和,检验和的数值是全 1。 (3)发送方使用检验和,检验和的数值是全 0。 (1)UDP 规定,UDP 的上层用户可以关闭检验和的计算(即在 UDP 的传送过程中,不使用检验和这个检错功能)。这样做的好处是可以提高 UDP 的传送速度(但要牺牲一些可靠性)。如果发送方决定不使用检验和,那么发送方的检验和的值应当置为全 0。这表示这个数值不是计算出来的,而是发送方关闭了检验和这个功能。 (2)如果发送方使用检验和,但检验和的数值是全 1。 我们可以想一想,怎么会出现这种情况。如果计算检验和最后的结果是全 1,就表明得出这个结果的前一个步骤(即二进制反码求和)的结果是全 0。在什么情况下,伪首部和整个 UDP 按 16 位字进行二进制反码求和的结果是全 0 ?这就是伪首部和整个 UDP 的所有字段都是 0。但很明显,这是不可能的。所有的地址和数据都是 0,还有什么意义?不要以为两个 1 相加就是 0。不对。两个 1 相加按二进制反码求和的结果是 1 0。这里的 1 是进位。因为此按照计算检验和的规矩来计算,对真实的 UDP 用户数据报不可能得出检验和的数值是全 1。 但是,计算检验和时的倒数第二步,即按二进制反码求和的结果却有可能是全 1。在这种情况下,最后一步求反码,就会得出检验和是全 0。但是前面我们已经讲过,检验和置为全 0是表示发送方不使用检验和。这样就产生了疑问:如果检验和是全 0,是发送方不使用检验和?还是使用了检验和但检验和的结果碰巧全是 0?无法确定。于是 UDP 协议就规定:如果计算检验和的结果刚好是全 0,那么就把它人为的置为全 1。因为前面已经讲过,全 1 的检验和是不可能由计算出来的。因此接收方一旦收到检验和为全 1 的 UDP 用户数据报,就知道这是人为的,真正地检验和其实是全 0。 (3)发送方使用检验和,检验和的数值是全 0。 前面已经讲过,这是不可能的。如果发送方计算出来的检验和是全 0,那也要把它变成全 1 再发送出去。 52.UDP 和 IP 的不可靠程度是否相同? 请加以解释。 ① UDP 和 IP 都是无连接的协议和不可靠传输的协议。UDP 用户数据报和 IP 数据报的首部都有检验和字段。当检验出现差错时,就把收到的 UDP 用户数据报或 IP 数据报丢弃。这是它们的相同之处。 ② 但 UDP 和 IP 的可靠性是有些区别的。UDP 用户数据报的检验和是既检验 UDP 用户数据报的首部又检验整个的 UDP 用户数据报的数据部分,而 IP 数据报的检验和仅仅检验 IP 数据报的首部。UDP 用户数据报的检验和还增加了伪首部,即还检验了下面的 IP 数据报的源 IP 地址和目的 IP 地址。 53.UDP 用户数据报的最小长度是多少?用最小长度的 UDP 用户数据报构成的最短 IP 数据报的长度是多少? UDP 用户数据报的最小长度是 8 字节,即仅有首部而没有数据。用最小长度的 UDP 源用户数据报构成的最短 IP 数据报的长度为 28 字节。此 IP 数据报具有 20 字节的固定首部,首部中没有可选字段。 54.某客户使用 UDP 将数据发送给一服务器,数据共 16 字节。试计算在运输层的传输效率(有用字节与总字节之比)。 58.TCP 在 4:30:20 发送了一个报文段。它没有收到确认。在 4:30:25 它重传了前面这个报文段。它在 4:30:27 收到确认。若以前的 RTT 值为 4 秒,根据 Karn 算法,新的 RTT 值为多少? 根据 Karn 算法,只要是 TCP 报文段重传了,就不采用其往返时间样本。本题中收到的确认是在重传后收到的。因此 RTT 没有变化,仍然是以前的数值(4 秒)。 Karn算法:运输层用来控制流量算法。在计算平均往返时延 RTT 时,只要报文段重传了,就不采用其往返时延样本。这样得出的平均往返时延 RTT 和重传时间就较准确。 59.TCP 连接使用 1000 字节的窗口值,而上一次的确认号是 22001。它收到了一个报文段,确认号是 22401.。试用图来说明在这之前与之后的窗口情况。 在这之前和在这之后的窗口情况如下图所示。 这里要注意的是:发送窗口为 1000 字节,窗口里面的序号也正好是 1000 个。号码小在后面,即在图的左方。另外一点要注意的是,发送方收到的确认号表示接收方期望能够收到序号。这个序号应当在发送窗口的最前面。 62.TCP 连接处于 ESTABLISHED 状态。以下的事件相继发生: (1)收到一个 FIN 报文段 (2)应用程序发送 “关闭” 报文 在每一个事件之后,连接的状态是什么?在每一个事件之后发生的动作是什么?
63.TCP 连接处于 SYN-RCVD 状态。以下的事件相继发生: (1)应用程序发送 “关闭” 报文 (2)收到 FIN 报文段 在每一个事件之后,连接的状态是什么?在每一个事件之后发生的动作是什么? 65.假定主机 A 向 B 发送一个 TCP 报文段。在这个报文段中,序号是 50,而数据一共有 6 字节长。试问,在这个报文段中的确认字段是否应当写入 56? 在这个报文段中的确认字段应当写入的是 A 期望下次收到 B 发送的数据中的第一个字节的编号,而这个数值是 A 已经收到的数据的最后一个字节的编号加 1。然而这些在题目中并未给出。题目给出的是 A 向 B 发送的数据中第一个字节的编号是 50,并且在这个报文段中共有 6 字节的数据。这些都和此报文段中的确认字段是什么毫无关系。因此,现在我们无法知道这个报文段中的确认字段应当写入的数值。 66.主机 A 通过 TCP 连接向 B 发送一个很长的文件,因此这需要分成很多个报文段来发送。假定某一个 TCP 报文段的序号是 x,那么下一个报文段的序号是否就是 x + 1 呢? 假定某一个 TCP 报文段的序号是 x,那么下一个报文段的序号应当是 x+n,这里的 n 是这个报文段中的数据长度的字节数。如 n = 4000,那么下一个报文段的序号应当是 x + 400。若此报文段中仅有一个字节的数据,则下一个报文段的序号才是 x + 1。 67.TCP 的吞吐量应当是每秒发送的数据字节数,还是每秒发送的首部和数据之和的字节数?吞吐量应当是每秒发送的字节数,还是每秒发送的比特数? ① TCP 的吞吐量本来并没有标准的定义,可以计入首部,也可以不计入首部,但应当说清楚。不过,从拥塞控制来看,拥塞窗口和发送窗口针对的都是 TCP 报文段中的数据字段,而重要的参数 MSS 也是指 TCP 报文段中的数据字段的长度,因此,把 TCP 的吞吐量定义为每秒发送的数据字节数是比较方便的。 ② 计算机内部的数据传送是以每秒多少字节作为单位的,而在通信线路上的数据率则常用每秒多少比特作为单位。这两种表示方法并无实质上的差别。在上面的习题中,因为 MSS 用字节作为单位,因此,用每秒发送多少字节作为 TCP 吞吐量的单位就比较简单一些。 68.在 TCP 的连接建立的三报文握手过程中,为什么第三个报文段不需要对方的确认?这会不会出现问题? ① 关于这个问题,还不能简单地用 “是” 或 “否” 来回答。 ② 我们假定 A 是客户端,是发起 TCP 连接建立一方。现在假定三报文握手过程中的第三个报文段(也就是 A 发送的第二个报文段 —— 确认报文)丢失了,而 A 并不知道。这是,A 以为对方收到了这个报文段,以为 TCP 连接已经建立,于是就开始发送数据报文段给 B。 ③ B 由于没有收到三报文握手中的最后一个报文段(A 发送的确认报文段),因此 B 就不能进入 TCP 的 ESTABLISHED 状态(“连接已建立” 状态)。B 的这种状态可以叫做 “半开连接” ,即仅仅把 TCP 连接打开了一半。在这种状态下,B 虽然已经初始化了连接变量和缓存,但是不能接收数据。通常,B 在经过一段时间后(例如,一分钟后) ,如果还没有收到来自 A 的确认报文段,就终止这个半开连接状态,那么 A 就必须重新建立 TCP 连接。因此,在这种情况下,第三个报文段(A 发送的第二个报文段)的丢失,就导致了 TCP 连接无法建立。 ④ 但是,假定 A 在这段时间内,紧接着就发送了数据。我们知道,TCP 具有累计确认的功能。在 A 发送的数据报文段中,自己的序号也没有改变,仍然是和丢失的确认真的序号一样(丢失的那个确认帧不消耗序号),并且确认位 ACK = 1,确认号也是 B 的初始序号加 1。当 B 收到这个报文段后,从 TCP 的首部就可以知道,A 已确认了 B 刚才发送的 SYN + ACK 报文段,于是就进入了 ESTABLISHED 状态(“连接已建立” 状态)。接着,就接收 A 发送的数据。在这种情况下,A 丢失的第二个报文段对 TCP 的连接建立就没有影响。 ⑤ 大家知道,A 在发送第二个报文段时,可以有两种选择: (1)仅仅是确认而不携带数据,数据接着在后面发送。 (2)不仅是确认,而且携带上自己的数据。 ⑥ 在第一种选择时,A 在下一个报文段发送自己的数据。但下一个报文的首部中仍然包括了对 B 的 SYN + ACK 报文段的确认,即和第二种选择发送的报文段一样。 ⑦ 在第二种选择时,A 省略了单独发送一个确认报文段。 从这里也可以看出,A 发送的第二个仅仅是确认的报文段,是个可以省略的报文段,即使丢失了也无妨,只要下面紧接着就可以发送数据报文段即可。 69.现在假定使用类似 TCP 的协议(即使用滑动窗口可靠传送字节流),数据传输速率是 1 Gbit/s,而网络的往返时间 RTT = 140 ms。假定报文段的最大生存时间是 60 秒。如果要尽可能快的传送数据,在我们的通信协议的首部中,发送窗口和序号字段至少各应当设为多大?
74.在上题中,如果接收方突然因某种原因不能够再接收数据了,可以立即向发送方发送把接收窗口置为零的报文段(即 rwnd = 0)。这时会导致接收窗口的前沿后退。试问这种情况是否允许? 这种情况是允许的。当发送方收到这样的信息,并不是把发送窗口缩回到零,而是立即停止发送。什么时候可以再发送数据,就要等接收方重新开放接收窗口,即给出一个非零的接收窗口。 74.流量控制和拥塞控制的最主要的区别是什么?发送窗口的大小取决于流量控制还是拥塞控制? 简单地说,流量控制是在一条 TCP 连接中的接收端才用的措施,用来限制对方(发送端)发送报文的速率,以免在接收端来不及接收。流量控制只控制一个发送端。 拥塞控制是用来控制 TCP 连接中发送端发送报文段的速率,以免使互联网中的某处产生过载。拥塞控制可能会同时控制许多个发送端,限制它们的发送速率。不过每一个发送端只知道自己应当怎样调整发送速率,而不知道在互联网中还有哪些主机被限制了发送速率。 我们知道,发送窗口的上限值是 Min [rwnd, cwnd],即发送窗口的数值不能超过接收窗口和拥塞窗口中娇小的一个。接收窗口的大小体现了接收端对发送端施加的流量控制,而拥塞窗口的大小则是整个互联网的负载情况对发送端施加的拥塞控制。因此,当接收窗口小于拥塞窗口时,发送窗口的大小取决于流量控制,即取决于接收端的接收能力。但当拥塞窗口小于接收窗口时,则发送窗口的大小取决于拥塞控制,即取决于整个网络的拥塞状况。 75.假定在 TCP 连接中刚刚收到的最新的往返时间 RTT 1 秒,那么超时重传时间 RTO 是否当设置成大于或等于 1 秒? 这不一定。超时重传时间 RTO 应当根据教材上的公式(5-4)和(5-5)来计算,而不是根据某一个 RTT 样本来计算。如果仅根据一个 RTT 样本就确定了超时重传时间 RTO,那么 RTO 的数值就可能会经常大幅度地波动。这就会使超时重传时间 RTO 的数值很不准确,使 TCP 的传输性能变坏。 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |